1. Field of the Invention
The present invention relates to a method, system, and program for copying data between primary and secondary storage locations subject to a copy relationship.
2. Description of the Related Art
Data backup systems can provide continuous availability of production data in the event of a sudden catastrophic failure at a single point in time or data loss over a period of time. In one such system, production data is mirrored from a local site to a remote which may be separated geographically by several miles from the local site. Such dual, mirror or shadow copies are typically made in a secondary storage device at the remote site, as the application system is writing new data to a primary storage device usually located at the local site. Different copy technologies may be used for maintaining remote copies of data at a secondary site, such as International Business Machine Corporation's (“IBM”) Metro Mirror Peer to Peer Remote Copy (PPRC), Extended Remote Copy (XRC), Coupled XRC (CXRC), Global Copy, and Global Mirror Copy.
In data mirroring systems, data is typically maintained in volume pairs, comprising a primary volume in a primary storage device and a corresponding secondary volume in a secondary storage device that includes an identical copy of the data maintained in the primary volume. The primary and secondary volumes are identified by a copy relationship. Primary and secondary storage controllers may be used to control access to the primary and secondary storage devices.
Geographically Dispersed Parallel Sysplex (GDPS) is an example of an application that customers may use to manage planned and unplanned outages. The GDPS application can detect failures at the primary storage system which may be at a local site, for example. Such failures may include a problem writing or accessing primary storage volumes at the local site. When the GDPS recovery application detects that a failure has occurred, it can invoke a swapping function referred to as the “HyperSwap” function. This function may be used to swap processing for all volumes in the mirrored configuration from the local site to the remote site. As a consequence of the swap, the storage volumes at the remote site which were originally configured as the secondary volumes of the original copy relationship, are reconfigured as the primary volumes of a new copy relationship. Similarly, the storage volumes at the local site which were originally configured as the primary volumes of the original copy relationship, may be reconfigured as the secondary volumes of the new copy relationship, once the volumes at the local site are operational again.
In connection with the swapping function, a failover function may be invoked. In the GDPS recovery application, the failover function can in some instances, obviate performing a full copy when re-establishing data replication in the opposite direction, that is, from the remote site back to the local site. More specifically, the failover processing resets or reconfigures the remote storage devices (which were originally configured as the secondary storage devices) to be the primary storage devices which are placed in a “suspended” status pending resumption of the mirroring operation but in the opposite direction. In the meantime, the failover processing starts change recording for any subsequent data updates made by the host to the remote site.
Once the local site is operational, failback processing may be invoked to reset the storage devices at the local site (which were originally configured as the primary storage devices) to be the secondary storage devices. Mirroring may then be resumed (but in the opposite direction, that is remote to local rather than local to remote) to resynchronize the secondary storage devices (originally the primary storage devices) at the local site to the data updates being stored at the primary storage devices (originally the secondary storage devices) at the remote site.
Copy services such as PPRC and data recovery programs which use copy services such as PPRC, frequently use various types of bitmaps stored in metadata. For example, bitmaps may be “static” bitmaps which are reserved for a particular function. Other bitmaps, often referred to as “dynamic” bitmaps, may be available for use by different functions and thus may be dynamically assigned to a function requesting a bitmap.
In general, the contents of static bitmaps are not known until they are initialized by the function reserved for that static bitmap. Dynamic bitmaps available for use by different functions, are typically initialized when created so that all bits of the bitmaps are initialized to a zero value. Once a function has completed use of a bitmap, the bitmap is considered to be “dirty” and thus is typically reinitialized (cleaned) before being used again.
The static and dynamic bitmaps are typically set up at the time the volumes are created. When a function requires a dynamic bitmap, it is assigned a bitmap index to an available dynamic bitmap. The value of this index which identifies the dynamic bitmap being assigned to the function, is typically kept in separate metadata until the bitmap is no longer in use.
In known copy services such as PPRC, an out-of-synch (OOS) bitmap is an example of a static bitmap reserved for the OOS function. An OOS bitmap includes a bit for each track of a primary storage location that storage controllers are to copy over to a corresponding track of a secondary storage location of a copy relationship. Thus, the out-of-synch bitmap indicates a backlog of tracks waiting to be copied. During normal copy operations, any writes to a storage controller for the primary storage location, are recorded in the out-of-synch bitmap (OOS) and then copied over to the secondary storage location.
Previously, processing of the swapping operation of failover commands such as the PPRC Failover command typically included initialization of the Out-Of-Sync (OOS) bitmap for all original remote volumes being reconfigured as primary volumes for the replacement copy relationship. The OOS bitmap is frequently stored as a data structure in metadata within the primary storage locations of the copy relationship. In a typical OOS bitmap, a zero bit indicates that no update has occurred for the data track of the primary storage location represented by that bit of the OOS bitmap. Hence, in many prior data recovery programs, the OOS bitmap is typically initialized to all zeros by accessing the metadata of the primary storage location and writing zeros to every bit position of the bitmap.